Capybara summary for PR 2178

• rec_dis_10x100_minQ2=0_craterlake_10x100
• rec_dis_10x100_minQ2=1000_craterlake_tracking_only
• rec_dis_18x275_minQ2=0_craterlake_18x275
• rec_dis_18x275_minQ2=0_craterlake_18x275_MT
• rec_dis_18x275_minQ2=0_craterlake_18x275_ST_MT
• rec_dis_18x275_minQ2=1000_craterlake_18x275
• rec_dis_18x275_minQ2=1000_craterlake_18x275_MT
• rec_dis_18x275_minQ2=1000_craterlake_18x275_ST_MT
• rec_dis_5x41_minQ2=0_craterlake_5x41
• rec_e_1GeV_20GeV_craterlake
• rec_pi_1GeV_20GeV_craterlake

Last updated 2025-11-17T22:33-05:00 7205da0

The test https://github.com/eic/EICrecon/blob/main/src/tests/algorithms_test/calorimetry_CalorimeterClusterRecoCoG.cc was written exactly to demonstrate the behaviour that was coded by Derek in the original version. I think we can fix the test in a straightforward way.

diff --git a/src/tests/algorithms_test/calorimetry_CalorimeterClusterRecoCoG.cc b/src/tests/algorithms_test/calorimetry_CalorimeterClusterRecoCoG.cc
index 62b22de08..e266b54c6 100644
--- a/src/tests/algorithms_test/calorimetry_CalorimeterClusterRecoCoG.cc
+++ b/src/tests/algorithms_test/calorimetry_CalorimeterClusterRecoCoG.cc
@@ -230,15 +230,18 @@ TEST_CASE("the calorimeter CoG algorithm runs", "[CalorimeterClusterRecoCoG]") {
   REQUIRE(clust_coll->size() == 1);
   auto clust = (*clust_coll)[0];
 
-  REQUIRE(assoc_coll->size() == 2);
+  REQUIRE(assoc_coll->size() == 3);
 
   // Half of the energy comes from mcpart11 and its daughter mcpart12
-  REQUIRE_THAT((*assoc_coll)[0].getWeight(), Catch::Matchers::WithinAbs(0.5, EPSILON));
+  REQUIRE_THAT((*assoc_coll)[0].getWeight(), Catch::Matchers::WithinAbs(0.25, EPSILON));
   REQUIRE((*assoc_coll)[0].getRec() == clust);
   REQUIRE((*assoc_coll)[0].getSim() == mcpart11);
+  REQUIRE_THAT((*assoc_coll)[1].getWeight(), Catch::Matchers::WithinAbs(0.25, EPSILON));
+  REQUIRE((*assoc_coll)[1].getRec() == clust);
+  REQUIRE((*assoc_coll)[1].getSim() == mcpart12);
 
   // Half of the energy comes from mcpart2
-  REQUIRE_THAT((*assoc_coll)[1].getWeight(), Catch::Matchers::WithinAbs(0.5, EPSILON));
-  REQUIRE((*assoc_coll)[1].getRec() == clust);
-  REQUIRE((*assoc_coll)[1].getSim() == mcpart2);
+  REQUIRE_THAT((*assoc_coll)[2].getWeight(), Catch::Matchers::WithinAbs(0.5, EPSILON));
+  REQUIRE((*assoc_coll)[2].getRec() == clust);
+  REQUIRE((*assoc_coll)[2].getSim() == mcpart2);
 }

Regarding the failing test, I'm not so sure anymore what behavior we want here as it depends. I can make the lookup code configurable in maximum number of steps below the "root" particle it goes, then the setup in CoG doesn't need to match the one in the SimCalorimeterHitProcessor anymore. I'll wait for @ruse-traveler to weigh in on the desired behavior. We can quite trivially make it configurable if need be.

Regarding the failing test, I'm not so sure anymore what behavior we want here as it depends. I can make the lookup code configurable in maximum number of steps below the "root" particle it goes, then the setup in CoG doesn't need to match the one in the SimCalorimeterHitProcessor anymore. I'll wait for @ruse-traveler to weigh in on the desired behavior. We can quite trivially make it configurable if need be.

In the test we have a situation where an electron emits a roughly collinear photon during the simulation stage and both contribute to a single hit. Then a pi0 contributes to a separate hit, and the 2 hits are grouped into a cluster. In this case, my thinking is that we would want associations back to only the electron & pi0 since the photon here is a secondary (presumably generated by an interaction with the trackers or services).

But if the photon was radiated during the generation stage, this would presumably happen before we had any chance to measure the electron before the radiation. In this case, I would think we could consider both as proper "primaries" and we would want associations back to all 3...

All that being said, I do think making it configurable would be really useful! Our definition of primary and gen-reco mappings are still very much WIPs after all.

To be honest, I'm surprised that the change picks up all 3 since the photon has a generator status of 0🤨

Today in the BIC simulation meeting I was wondering about two questions:

1. What are the practical configurations where a single hit contains contribution from two daughters of primary particle? Decay vertex of such particle should be close or within the hit volume itself (i.e. beginning shower).
2. What are the conceptual difference between a hit and a cluster? They have a different size, but you could argue that studies for e.g. Bremsstrahlung radiation are valuable case as well.
3. The current depth criteria (steps=0) will attribute next shower steps to the primary particle in addition to associations to the daughters (e.g. photon that you were looking after deposits energy and pair converts). This makes analysis of such information a bit unreliable.

The proposal is that the proposed implementation could be used to do studies using private simulations, then you can confirm for yourself if the algorithm is viable. In addition, it would help to understand this by having a unit test available with demonstration of some cases that were intended.

To be honest, I'm surprised that the change picks up all 3 since the photon has a generator status of 0🤨

Ah! Apologies! I was being a dummy: this is the intended behavior, since the goal is to associate to the electron and photon after the radiation.

Hi Folks - see below:

1. What are the practical configurations where a single hit contains contribution from two daughters of primary particle? Decay vertex of such particle should be close or within the hit volume itself (i.e. beginning shower).

That is not what we try to avoid - ambiguity within a single hit likely should be tracked to the parent. However, there are 2 places where this is relevant:

• Say we have an electron that radiates a photon while interacting with the tracker. The radiated photon travels in a straight line while the electron curves in the magnetic field. Because of this, they hit the calorimeter in different spots. If we navigate back to the original generated particle we now have 2 groups of hits (2 would-be clusters) associated with one single MC particle. This looses crucial information on what actually happened in the detector as the actual hit pattern corresponds to an electron + photon.
• If we give an undecided unstable particle to the GEANT simulation, GEANT will decay it, which can lead to a similar scenario.

2. What are the conceptual difference between a hit and a cluster? They have a different size, but you could argue that studies for e.g. Bremsstrahlung radiation are valuable case as well.

Not sure I understand this question.

3. The current depth criteria (steps=0) will attribute next shower steps to the primary particle in addition to associations to the daughters (e.g. photon that you were looking after deposits energy and pair converts). This makes analysis of such information a bit unreliable.

I wonder if that really happens, as in general showers shouldn't happen outside the tracking volume. Of course, sometimes they do (e.g. in the support cone). Is your worry that some showers are associated with the primary particle, but a very small fraction where the first 2 particles happen to be tracked it would be associated to those?

The proposal is that the proposed implementation could be used to do studies using private simulations, then you can confirm for yourself if the algorithm is viable. In addition, it would help to understand this by having a unit test available with demonstration of some cases that were intended.

I think there's a way to serve all cases, I need to think a bit about it as it's not immediately obvious what the best way out is (without making everything more complicated that it has to be).

But if the photon was radiated during the generation stage, this would presumably happen before we had any chance to measure the electron before the radiation. In this case, I would think we could consider both as proper "primaries" and we would want associations back to all 3...

I was also being foolish here: the intent of the change, of course, is that we're no longer associating to just primaries but also to relevant secondaries. With this change, we should associate to each.

But following up on this and the BIC simulation meeting today, let me elaborate a little on what the intended behavior was with the current association scheme.

When we switched to it, the primary goal was to reflect the fact that multiple particles can contribute to a single cluster. The selection of only primaries (i.e. status == 1) was mostly a practical choice:

• it was an improvement over what was there originally (picking the 1st contributor);
• it was straightforward to implement;
• and it better captures the topology of the event graph.

But this clearly leaves a lot to be desired (e.g. splash from the beampipe in the LFHCAL is completely absent in this scheme): it's very coarse-grained. I think the change here moves in the right direction by expanding associations to include (relevant) secondaries.

Hi Folks - see below:

1. What are the practical configurations where a single hit contains contribution from two daughters of primary particle? Decay vertex of such particle should be close or within the hit volume itself (i.e. beginning shower).

That is not what we try to avoid - ambiguity within a single hit likely should be tracked to the parent. However, there are 2 places where this is relevant:

• Say we have an electron that radiates a photon while interacting with the tracker. The radiated photon travels in a straight line while the electron curves in the magnetic field. Because of this, they hit the calorimeter in different spots. If we navigate back to the original generated particle we now have 2 groups of hits (2 would-be clusters) associated with one single MC particle. This looses crucial information on what actually happened in the detector as the actual hit pattern corresponds to an electron + photon.
• If we give an undecided unstable particle to the GEANT simulation, GEANT will decay it, which can lead to a similar scenario.

These are very good reasons, we want to enable all these studies. There might be caveats that I discuss below.

2. What are the conceptual difference between a hit and a cluster? They have a different size, but you could argue that studies for e.g. Bremsstrahlung radiation are valuable case as well.

Not sure I understand this question.

Above you were suggesting that CoG (Clustering) configuration nee not match the configuration in SimCalorimeterHitProcessor (Hits), and I see there is either a commonality or a difference that we'd want to explain here.

3. The current depth criteria (steps=0) will attribute next shower steps to the primary particle in addition to associations to the daughters (e.g. photon that you were looking after deposits energy and pair converts). This makes analysis of such information a bit unreliable.

I wonder if that really happens, as in general showers shouldn't happen outside the tracking volume. Of course, sometimes they do (e.g. in the support cone). Is your worry that some showers are associated with the primary particle, but a very small fraction where the first 2 particles happen to be tracked it would be associated to those?

My impression was that when we developed the original code people were reporting seeing interaction vertices outside of the tracking region. I think, and @ruse-traveler can correct me on that, no one at the time understood what exactly was the logic DD4hep was following, and that was the reason why the final algorithm ended up being so simple. There is also a valid reason why we might want to extend the tracking region to the faces of the hadronic calorimeters for some types of analysis. Maybe all of this can be addressed by an algorithm that is aware of not only the topology of the event record, but also the vertex positions themselves (and/or particle types).

The proposal is that the proposed implementation could be used to do studies using private simulations, then you can confirm for yourself if the algorithm is viable. In addition, it would help to understand this by having a unit test available with demonstration of some cases that were intended.

I think there's a way to serve all cases, I need to think a bit about it as it's not immediately obvious what the best way out is (without making everything more complicated that it has to be).

Okay, maybe now I get that what you are doing serves all cases, we just need to better investigate how to actually do what you want.

Forgot to add to point 1. I guess, you are not strictly losing the information in that case. There are still MCParticle records, the associations are not entirely ambiguous if the hits are separate and can be matched to projections. That was partially the source of my original confusion.